그림으로 배우는 HTTP & Network basic 1

HTTP 약점

1. http의 약점

   • 평문(암호화 하지 않은) 통신이기 때문에 도청이 가능하다. TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있다.

   • 통신 상대를 확인하지 않기 때문에 위장 가능하다.

     • 누구나 리퀘스트 할 수 있기 때문에 실제로 의도한 송신자인지 알 수 없다.
   • 완전성을 증명할 수 없기 때문에 변조가 가능하다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신할 때까지의 사이에 변조되었더라도 변조된 사실을 알 수없다. 공격자가 도중에 요청이나 응답을 빼았아 변조하는 공격인 man in the middle attack이 가능하다.

2. 위의 약점들의 보완 방법

   1. 도청

      • 통신 암호화
      • 컨텐츠 암호화

   2. 위장

      • 상대를 확인하는 증명서

   3. 완전성

      • sha-1이나 md5 같은 해시함수로 해시값을 통신 확인.

3. HTTPS = HTTP + 암호화 + 인증 + 완전성 보호

   1. 암호화 방식

      • 공통키 암호화 방식(symetic)

        • 클라이언트 서버가 동일한 암호 key를 갖고 내용을 키로 암호화 하여 통신하는 방법.

      • 공개키 암호화 방식(asymentic)

        • 한쌍의 key pair를 가진다.public key , private key라고 한다.
        • public key로 암호화 하면 private키로만 복호화가 가능하고, private key로 암호화 하면 public key로만 복호화가 가능하다.
        • private key로 public key를 생성할 수 있으며 반대로는 불가능하다.

   2. 공통키를 어떻게 교환할까

      • 문제 : 공통키를 외부에 노출하면 누구나 암호화된 것을 볼 수 있기 때문에 전송의 문제가 된다.
      • 해결 : 서버가 개인키를 갖고, 공개키를 클라이언트에게 주고 클라이언트에게 개인키로 암호화된 공통키를 전송한다. 클라이언트는 공개키로 공통키를 얻어 통신할 수 있음.

      • 장점

        • 공통키에 비해 공개키는 연산이 느리기 때문에 위와 같은 방법을 사용하면 공통키의 빠른 암호 복호화 속도로 통신이 가능함.
   3. HTTPS는 공통키 공개키 두가지 방법을 모두 사용한다.
   4. 근데 실제로 완전성 보호에 대한 이야기는 나와있지 않는듯 하다.(이부분은 생각해보자.)

4. 공개키가 내가 원하는 서버의 공캐기인지 증명할 수 있는 증명서

   • 문제 : 클라이언트는 자신이 원하는 서버의 공개키인지 알수가 없다. 도중에 해커가 자신의 공개키를 넘겨줄 수도 있기 때문이다.
   • 해결 : 인증 기관(Certificate Authority)과 그 기관이 발행하는 공개키 증명서를 이용한다.

   • 절차

     1. 서버의 공개키를 인증기관에 등록한다
     2. 인증 기관의 비밀키로 서버의 공개키에 디지털 서명(암호화)으로 공개키 증명서를 작성 등록한다.
     3. 클라이언트는 서버의 공개키 증명서를 입수하고, 디지털 서명을 인증 기관의 공개키로 검증하고, 공개키가 진짜인지 확인한다.
     4. 서버의 공개키로 암호화 해서 메시지를 서버에 전송한다.
     5. 서버의 비밀키로 클라가 전송한 메시지를 복호화 한다.
   • 인증 기관은 서버들이 신뢰성을 갖는지 확인하고, 사용자들이 볼 수 있도록 증명서에 회사의 정보를 넣기도 한다. 그것을 EV SSL 증명서라고 한다.

5. 클라이언트를 확인하는 클라이언트 증명서

   • 문제 : 서버도 클라이언트가 실제로 알고있는 클라이언트인지 증명할 수가 없다.
   • 해결 : 클라이언트를 확인하는 클라이언트 증명서를 사용한다.

   • 단점

     1. 증명서를 유료로 구입해야 된다.
   • 사용 예 : 은행 공인인증서.

6. 인증기관에 전적으로 의존적

   • 결국 위의 모든 방법은 인증기간이 얼마나 성실히 일을 잘하냐에 따라 달려있다. 잘못된 인증을 하게 되면 문제가 될 수 있다.
   • 증명서를 무효화 하는 증며엇 취소 리스트(CRL)구조나 루트 인증기관을 클라이언트에서 삭제하는 대책이 있지만, 시간이 오래걸리고 그동안 피해자가 생길 수 있다.

7. 쓰레기 인증 기관

   • OpelSSL 등의 소프트웨어를 사용하면 누구든지 인증 기관을 구축할 수 있어서 서버 증명서를 발행할 수 있다.
   • 이것을 나야 나 증명서라고 하는데 위장의 가능성이 크다.
   • 마이너 인증 기관 또한 나야나 증명서가 될 수 있다.

8. HTTPS 통신 절차

   1. 클라이언트가 SSL 통신을 시작함. 메시지에 클라이언트가 제공하는 SSL 버전과 암호 suite(사용할 수 있는 암호방식)로 불리는 리스트 등이 포함된다.
   2. server는 클라이언트와 같이 SSL 버전과 클라에서 받은 암호방식중 선택하여 알려준다.
   3. 서버가 certificate 메시지를 송신한다. 메시지에는 공개키 증명서가 포함되있다.
   4. 서버가 최초의 SSL negotiation 부분이 끝났음을 통지하는 메시지를 전송한다.
   5. Client Key Exchange 메시지로 응답하고, 메시지에는 통신을 암호화 하는데 사용하는 Pre-Master secret 이 포함되어져 있다. 이 메시지는 3의 공개키 증명서에서 꺼낸 공개키로 암호화 되어 있다.
   6. 클라이언트는 Change Cipher Spec 메시지를 송신하며 이 메시지에는 이 메시지 이후의 통신은 암호키를 사용해서 진행한다는 것을 나타낸다.
   7. 클라이언트는 finished 메시지를 송신하며 접속 전체의 체크값을 포함한다. 협상을 성공했는지 어떤지는 서버가 이 메시지를 복호화할 수 있는지 아닌지가 결정한다.
   8. 서버도 change cipher spec 메시지를 전송한다.
   9. 서버에서도 finished 메시지를 전송한다
   10. 서버와 클라의 finished 메시지 교환이 완료 되면 SSL에 의해 접속이 확립된다. 이제부터 HTTP리퀘스트를 송신하고 통신한다.
   11. 서버가 응답한다
   12. 마지막에 접속을 끊을경우 close_notify메시지를 전송한다.
   13. 어플리케이션 계층의 데이터를 송신할 때에는 MAC(Message Athentication Code)라고 부르는 메시지 다이제스트를 붙힐수 있다.

9. TLS, SSL의 단점.

   • connection을 맺는 절차가 길어 통신속도가 느릴 수 있다.
   • 암호화 복호화를 하는 시간으로 자원을 많이 소요한다.